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Recent  technological  advances  have  nade  possible  so- 
phisticated data-gathering  capabilities  for  earth-orbiting 
spacecraft.  Naval  forces  would  appear  to  be  particularly 
vulnerable  to  satellite  surveillance  since  they  operate  on 
the  surface  of  uniform,  low-noise  oceans  where  camouflaging 
is  difficult.  Thus  the  problem  facing  the  commander  of  a 
task  force  is  how  to  move  his  force  when  secrecy  is  important. 


A methodology  is  presented  for  helping  a naval  comman- 
der avoid  satellite  surveillance.  With  known  satellite 
orbital  characteristics,  the  time  and  location  of  detection 
zones  along  a ship's  planned  route  can  be  calculated.  The 
methodology  suggests  how  a commander  can  avoid  many  of  these 
detection  zones  by  varying  his  speed  of  advance  (SOA)  during 
his  transit. 


A computer  decision  aid  based  on  this  methodology  has 
been  developed.  It  considers  probabilistic  information, 
such  as  the  probability  that  the  weather  will  permit  detec- 
tion by  a given  satellite  and  the  probability  that  a partic- 
ular evasive  action  will  thwart  detection,  along  with  user 
provided  cost  functions  for  factors  such  as  aversion  to 
detection  and  costs  of  evasive  actions  to  calculate  expected 
cost  for  the  detection  zones  encountered  using  a given  SOA 
profile.  A dynamic  programming  algorithm  is  then  used  to 
determine  the  SOA  profile  which  minimizes  expected  cost  for  . 
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SATELLITE  SURVEILLANCE  AVOIDANCE  OPTIMIZATION  AID 


1.0  INTRODUCTION 


Adversary  surveillance  has  long  been  a concern  of  naval 
commanders  at  sea.  Not  only  can  it  identify  a naval  task 
force  as  a possible  military  target,  but  it  may  also  lead  to 
an  unwanted  confrontation  with  possibly  far  greater  military 
and  political  consequences. 

Ships  at  sea  are  potentially  subject  to  many  kinds  of 
surveillance.  Traditionally,  the  important  components  of  a 
surveillance  system  have  been  aircraft,  shipping,  submarines, 
land-based  radar,  and  communications  sensors.  Future  sur- 
veillance systems  can  be  expected  to  include  land-based 
acoustic  sensors  and  earth-orbiting  satellites  with  varied 
sensing  capabilities. 

It  is  possible  to  avoid  some  of  these  surveillance 
systems  by  careful  pre-transit  planning.  In  many  cases,  the 
task  force  commander  may  plan  to  avoid  areas  of  the  ocean  in 
which  he  is  likely  to  be  detected  by  land-based  sensors, 
merchant  traffic,  aircraft,  or  submarines.  In  addition,  he 
may  plan  to  follow  a deceptive  route  so  that,  if  he  is 
detected,  his  intentions  and  destination  will  be  difficult 
to  infer.  The  result  of  this  planning  would  be  a track 
plan,  which  consists  of  a specified  transit  route.  A hypo- 
thetical track  plan  from  Norfolk,  Virginia  to  the  Straits  of 
Gibraltar  is  illustrated  in  Figure  1-1. 

The  presence  of  satellites  with  surveillance  capabilitie 
would  greatly  diminish  the  effectiveness  of  a track  plan, 
which  is  intended  to  circumnavigate  areas  of  the  ocean  where 
surveillance  is  likely.  Since  surveillance  satellites  can 
cover  all  areas  of  the  ocean,  a track  plan  by  itself  would 


Figure  1-1 

HYPOTHETICAL  TRACK  PLAN  FROM  NORFOLK  TO  GIBRALTAR 


be  an  ineffective  countermeasure  for  satellite  surveillance. 

The  task  force  conunander  can,  however,  predict  a 
satellite's  motion  and  use  that  information  to  his  advantage. 

The  ephemeris  data  for  an  adversary  satellite  is  either 
known  or  can  be  calculated  from  observation  data.  The 
ground  track,  which  is  traced  out  by  movement  of  the  satellite's 
sub-orbital  point  across  the  earth's  surface,  can  then  be 
predicted  with  precision.  The  satellite's  ground  track  will 
usually  intersect  the  commander's  track  plan  at  regular, 
predictable  intervals. 

One  pass  of  a satellite  over  the  track  plan  is  represented 
by  the  ground  track  segment  A in  Figure  1-2.  The  dotted 
lines  on  either  side  of  A represent  the  satellite's  effective 
field  of  vision.  If,  at  the  time  of  this  pass,  the  task 
force  is  in  the  segment  of  its  track  plan  within  this  field 
of  vision,  then  detection  is  possible. 

As  the  satellite  follows  its  orbital  trajectory,  the 
earth  precesses  from  west  to  east  underneath  it.  Thus, 
after  one  orbital  revolution,  the  same  satellite  may  again 
cross  the  track  plan  with  ground  track  B,  which  is  to  the 
west  of  A. 

A typical  non- synchronous  satellite  with  surveillance 
capabilities  normally  has  an  orbital  period  of  about  ninety 
minutes.  The  time  interval  between  successive  detection 
zones,  like  those  associated  with  A and  B,  is  roughly  equal 
to  one  orbital  period,  depending  on  the  angle  of  inclination 
between  the  ships'  track  plan  and  the  satellite's  ground 
track.  Furthermore,  from  the  vantage  point  of  the  task 
force  commander,  each  detection  zone  lasts  for  only  a few 
minutes  because  the  satellite  moves  so  quickly;  for  a 
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Figure  1-2 

SATELLITE  PASSES  OVER  A HYPOTHETICAL  TRACK  PLAN 


satellite  having  a ninety-minute  orbital  period  and  an 
effective  swath  diameter  of  1,000  nautical  miles,  the 
ships'  exposure  time  to  surveillance  would  be  less  than  four 
minutes . 

Thus,  each  detection  zone  in  Figure  1-2  occurs  at  a 
particular  time  and  lasts  for  only  a few  minutes.  Even  if 
the  commander  must  depart  from  his  origin  and  arrive  at  his 
destination  at  specified  times,  he  may  be  able  to  avoid  sur- 
veillance from  satellite  passes  A and  B entirely  by  changing 
his  speed  of  advance  (SOA)  at  appropriate  points  enroute. 

If  the  transit  requires  several  days,  however,  a given 
satellite  would  normally  pass  over  the  track  plan  many 
times,  and  selecting  the  appropriate  SOA  to  use  at  vai ious 
times  may  become  rather  complex.  The  problem  is  further 
complicated  when  there  are  many  surveillance  satellites, 
each  with  different  orbital  characteristics  and  sensing 
capabilities . 

The  methodology  discussed  in  this  report  was  developed 
to  help  the  naval  commander  understand  during  transit  planning 
exactly  what  satellite  surveillance  he  faces  and  what  he  can 
do  to  avoid  it.  This  methodology  has  been  incorporated  into 
a computer  implementation  called  the  Satellite  Surveillance 
Avoidance  Optimization  Aid.  This  Aid  is  planned  to  be 
installed  in  the  Advanced  Command  and  Control  Architectural 
Testbed  (ACCAT)  at  the  Naval  Ocean  Systems  Center  (NOSC)  in 
San  Diego  in  order  to  test  the  efficacy  of  the  concepts 
which  it  embodies  and  to  determine  desirable  enhancements. 


2.0  GENERAL  METHODOLOGY 


The  basic  approach  developed  by  DDI  to  aid  the  naval 
commander  in  avoiding  surveillance  by  satellites  is  outlined 
in  this  section.  The  essence  of  the  approach  is  to  deter- 
mine for  a planned  transit  route  a series  of  speeds  of 
advance  which  avoid  placing  the  task  force  in  regions  of  the 
route  within  the  view  of  satellites  overhead  at  any  instant 
in  time. 

First,  the  approach  is  described  in  an  intuitive  manner 
using  a graphical  representation  of  the  problem.  Next,  the 
limitations  of  this  simplistic  solution  are  discussed. 

Finally,  a generalized  version  of  the  approach  is  described. 

2. 1 A Graphical  Representation 

The  satellite  surveillance  zones  along  a track  plan  and 
some  possible  ways  to  avoid  them  can  be  represented  graphically. 
For  illustration,  assume  that  a commander  is  required  to 
leave  Norfolk  at  4 P.M.  on  November  27  (Greenwich  mean  time) 
and  is  expected  to  arrive  at  Gibraltar  nine  days  later,  at  4 
P.M.  on  December  6. 

He  first  selects  a track  plan,  which  may  be  along  a 
great  circle  or  along  a more  complicated  route  consisting  of 
great  circle  segments.  Helping  the  commander  select  a track 
plan  is  beyond  the  scope  of  this  methodology  since  that 
decision  depends  on  many  transit-specific  factors  such  as 
the  location  of  land  masses,  shipping  lanes,  and  land-based 
adversary  surveillance. 


Suppose  that  a track  plan  like  that  in  Figure  1-1 


has  been  selected  and  that  the  length  of  the  transit  according 
to  this  plan  is  3,240  nautical  miles.  Figure  2-1  represents 
the  distance  along  the  track  plan  on  the  vertical  axis. 

Time  after  departure  is  represented  on  the  horizontal  axis. 

Each  vertical  line  segment  in  Figure  2-1  represents  a 
satellite  passing  over  a portion  of  the  track  plan.  Assume, 

for  example,  that  pass  A in  Figure  1-2  occurs  sixteen  hours 

after  the  departure  from  Norfolk.  That  pass  is  then  repre- 
sented by  line  segment  A in  Figure  2-1.  The  length  and 

vertical  position  of  this  line  segment  specify  the  portion 
of  the  track  plan  that  is  within  the  satellite's  effective 
field  of  vision.  The  horizontal  position  of  the  segment 
shows  the  time  when  this  pass  occurs  (16  hours  after  departure), 
and  its  width  is  the  exposure  time.  As  indicated  above, 
since  the  exposure  time  would  be  just  a few  minutes  for  a 
non-synchronous  satellite,  the  line  segment  is  very  thin 
when  plotted  on  a time  scale  measured  in  days. 

After  one  orbital  period,  the  satellite  again  passes 
over  the  track  plan  and  generates  another  line  segment,  B. 

In  a similar  fashion,  each  pass  of  the  satellite  over  the 
track  plan  during  the  nine-day  period  can  be  represented.^ 

Note  that  these  line  segments  can  be  calculated  and  plotted 
by  computer  for  any  given  departure  and  arrival  times,  track 
plan,  and  satellite  ephemeris  data. 

The  ships'  position  along  the  track  plan  at  any  point 
in  time  can  also  be  represented  on  this  graph.  As  the  task 


Figure  2-1  was  generated  for  a satellite  with  optical  sensors 
only.  Since  these  sensors  cannot  "see"  at  night,  nighttime 
passes  were  not  plotted.  A similar  graph  for  an  infrared 
satellite,  which  is  not  affected  by  darkness,  would  show 
about  twice  as  many  detection  zones. 
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force  moves  from  Norfolk  to  Gibraltar,  it  traces  out  a path 


i;  from  the  lower- left  to  the  upper-right  corner  of  the  graph.  j 

i A task  force  that  moves  with  a steady  15-knot  speed,  for  { 

[ example,  makes  the  3,240-mile  transit  in  exactly  nine  days  \ 

[ and  traces  out  the  diagonal  path  shown.  This  path  passes  j 

I 

through  eight  detection  zones.  The  commander  can  avoid  some  j 

of  these  detection  zones  by  varying  his  speed  enroute.  For 
example,  if  he  follows  the  SOA  profile  V in  Figure  2-2,  he 
will  encounter  only  three  detection  zones.  j 

I 

Avoidance  of  detection  zones  would  be  a rather  simple 
matter  if  ships  could  move  at  any  desired  speed.  Realistically, 
however,  there  are  constraints  within  which  the  commander  ' 

must  operate.  For  example,  he  may  wish  to  arrive  on  schedule 
and  to  use  speeds  that  are  between  5 and  25  knots.  These 
requirements  limit  his  possible  speed  profiles  to  those 
within  the  parallelogreun  in  Figure  2-2.  If  the  task  force 
travels  at  the  minimum  speed  of  5 knots  for  the  first  four 
and  a half  days,  it  will  trace  out  boundary  a.  Then,  in 
order  to  arrive  on  time,  it  would  have  to  use  maximum  speed 
for  the  rest  of  the  way,  following  boundary  b.  Boundaries  c 
and  d may  be  similarly  interpreted.  If  all  detection  zones 
are  assumed  to  have  equal  importance,  the  speed  profile  V is 
an  optimal  solution  within  these  constraints. 

If  there  are  several  surveillance  satellites,  however, 
the  task  of  avoiding  detection  zones  becomes  more  complex. 

The  detection  zones  for  five  hypothetical  surveillance 
satellites  are  plotted  in  Figure  2-3.  By  using  a steady  15- 
knot  speed  in  this  case,  the  commander  would  face  forty-two 
detection  zones  during  his  nine-day  transit.  It  may  still 
be  possible  to  plot  a series  of  speeds  of  advance  on  the 
graph  that  avoids  many  of  these  detection  zones,  although  it 
becomes  extremely  difficult  for  large  numbers  of  satellites. 
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2. 2 Limitations  Of  The  Graphical  Approach 


If  all  detection  zones  are  equally  important  to  avoid, 
then  the  solution  approach  suggested  above  is  a good  one: 
trace  a path  through  the  maze  of  detection  zones  which 
misses  as  many  as  possible  without  exceeding  the  maximum 
speed  of  advance,  or  falling  below  the  minimtim  speed  of 
advance. 

Passing  through  a detection  zone,  however,  does  not 
necessarily  mean  that  the  task  force  will  be  detected.  If 
cloudy  weather  is  forecast  for  the  first  few  days  of  the 
transit,  for  example,  the  probability  of  detection  by  an 
optical  satellite  during  that  period  will  probably  be  very 
small.  At  the  Seime  time,  the  sensing  capabilities  of  a 
radar  satellite  generally  are  not  affected  by  cloud  cover. 
Accordingly,  it  may  be  preferable  to  pass  through  two  or 
more  optical  detection  zones  rather  than  a single  radar 
detection  zone.  Therefore,  the  probability  of  detection 
within  a detection  zone,  which  is  not  represented  in  Figure 
2-3,  may  be  an  important  consideration  in  choosing  a speed 
profile. 

The  cost  of  a detection  may  also  be  important.  Are 
early  detections  more  costly  than  later  ones?  Is  the  first 
detection  more  costly  than  subsequent  detections?  In  addition, 
all  speeds  of  advance  are  not  equally  costly.  It  may  be 
preferable  to  risk  a detection  which  has  a low  probability 
rather  than  maintain  the  maximxim  speed  of  advance  for  an 
extended  period  of  time. 

If  models  for  the  probability  of  a detection,  the  cost 
of  a detection  within  each  detection  zone,  and  costs  of 
speeds  of  advance  are  available,  then  we  can  select  the  SOA 


12 


1 


profile  that  minimizes  the  expected  cost  of  the  transit. 

Finally,  it  may  be  possible  to  lower  the  probability  of 
being  detected  by  a given  satellite  through  the  use  of 
various  evasive  actions  such  as  EMCON,  electronic  counter- 
measures, etc.  Both  the  efficacy  and  costs  of  these  measures 
should  be  included. 

2. 3 Generalized  Approach 

Using  the  methodology  discussed  above,  a computer-based 
decision  Aid  for  helping  the  naval  commander  to  avoid 
satellite  surveillance  has  been  developed.  An  overview  of 
the  Aid  is  shown  in  Figure  2-4. 

The  Aid  is  designed  so  that  only  a small  number  of 
parameters  is  required  as  user  inputs.  Important  probabilistic 
information  and  current  satellite  ephemeris  data  are  assumed 
to  be  supplied  through  a land-based  computer  network.  Based 
on  inputs  from  the  network  and  the  user,  the  optimization 
procedure  provides  the  commander  with  a recommended  SOA 
profile  and  all  relevant  satellite  surveillance  information. 
Since  development  and  integration  of  the  components  of  such 
a system  are  no  small  tasks,  an  operational  version  of  the 
Aid  is  still  years  away. 

2.3.1  Optimization  Procedure  - A dynaunic  prograim 
searching  over  discrete  SOA  options  is  used  to  find  a 
recommended  SOA  profile  through  a pattern  of  detection 
zones.  In  consideration  of  the" limitations  discussed  in 
Section  2.2,  a probability  model  is  used  to  compute  the 
probability  of  detection  within  each  detection  zone,  and 
cost  profiles  for  detection,  evasive  actions,  and  speed 
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of  advance  are  are  obtained  from  the  user.  Then,  the 
recommended  SOA  profile  is  computed  as  the  one  that  minimizes 
the  expected  cost  of  the  transit. 

2.3.2  User  inputs  - Required  user  inputs  are  listed  in 
Figure  2-5.  First  the  user  must  supply  the  departure  time 
and  arrival  time.  Ordinarily  these  parameters  are  treated 
as  though  they  were  fixed  during  the  optimization  process; 
that  is,  the  optimizer  will  assume  departure  is  on  time  and 
will  assure  on-time  arrival.  However,  if  the  user  is  willing 
to  allow  a zero  speed  of  advance  as  a possibility,  the 
optimizer  will  suggest  that  the  task  force  depart  late  or 
arrive  early  if  there  is  any  advantage  in  doing  so. 

Next,  the  departure  point,  the  intermediate 
points  (if  any)  and  the  destination  are  supplied,  defining 
the  user's  track  plan.  If  no  intermediate  coordinates  are 
specified,  a great  circle  route  is  assumed. 

Once  the  track  plan  specification  has  been 
completed,  the  Aid  will  ask  the  user  to  assess  the  probability 
of  already  being  tracked  as  he  leaves  his  point  of  departure. 
For  example,  it  may  normally  be  the  case  that  adversary 
ships  in  the  area  of  the  departure  point  are  certain  to  take 
notice  of  his  departure.  In  this  case  there  will  be  a 
higher  probability  that  later  satellite  intersections  will 
result  in  a detection. 

The  second  phase  of  the  transit  plan  definition 
sequence  begins  with  the  specification  of  the  SOA  options  to 
be  considered  in  the  optimization  process.  The  user  is 
asked  to  do  this  by  providing  a minimum  value,  a maximum 
value,  and  an  increment.  Although  the  example  in  Figure 
2-5  shows  these  values  to  be  multiples  of  5,  this  is  not 
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• Departure  and  arrival  times 

• Track  plan  (point  of  departure,  destination,  and  intermediate  points) 

• Probability  of  already  being  tracked  at  departure 

• SOA  options 

(e.g.,5,  10,  15,  20,  25  knots) 

• Time  increment  for  SOA  changes 

(e.g.,  8 hours) 

• Fuel  costs 

• Detection  aversion  costs 

• Evasive  action  costs 

Figure  2-5 
USER  INPUTS 
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a requirement;  the  only  restriction  is  that  the  minimum  SOA 
and  the  maximum  SOA  must  be  multiples  of  the  SOA  increment. 
The  minimum  SOA  may  in  fact  be  zero  or  negative. 


Following  the  specification  of  SOA  options,  the 
Aid  asks  the  user  to  select  a time  increment  to  be  used  in 
the  optimization  process  as  the  length  of  time  over  which 
SOA's  will  be  maintained.  When  a particular  SOA  value  is 
chosen  by  the  optimizer,  the  user  is  expected  to  maintain 
that  speed  for  his  task  force  for  the  duration  of  the  time 
increment  specified.  The  optimizer  will  consider  changing 
speeds  only  at  times  which  are  multiples  of  this  time  increment. 

For  the  excimple  shown  in  Figure  2-5,  the  time 
increment  of  8 hours  has  been  chosen.  Thus,  the  optimizer 
will  consider  SOA  changes  with  a frequency  of  three  times  a 
day. 

The  next  portion  of  the  transit  plan  definition 
process  is  concerned  with  the  assessment  of  "fuel  costs." 

The  user  is  asked  to  specify  the  relative  "costs"  of  the 
various  SOA  options  with  respect  to  one  another  and  with 
respect  to  other  criteria  considered  later  in  the  elicitation 
process,  namely,  detection  aversion  and  evasive  action 
costs . 

The  fuel  costs  assessed  here  ordinarily  reflect 
more  than  just  the  cost  of  fuel  associated  with  each  SOA 
option.  They  indicate  the  user's  aversion  to  using  each 
particular  SOA  option  relative  to  the  others  (and  relative 
to  the  other  two  criteria)  for  any  reason  whatsoever.  For 
example,  the  user  may  prefer  an  SOA  of  10  knots  to  one  of  5 
knots  because  his  ships  do  not  respond  as  well  to  the  helm 
in  heavy  seas  at  the  slower  speed. 
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Detection  aversion,  like  fuel  costs,  must  be 
assessed  in  relation  to  the  entire  set  of  cost  criteria. 
Detection  aversion  is  a measure  of  the  cost  to  the  user  if  he 
were  detected  during  his  planned  transit  (and  identified  as 
a target  of  interest)  by  hostile  surveillance  forces.  Like 
fuel  costs,  aversion  to  detection  could  be  expressed  simply 
as  a single  value.  It  may  happen,  however,  that  a user's 
aversion  to  detection  varies  as  a function  of  his  progress 
through  his  transit.  In  particular,  the  user  may  be  more 
concerned  with  detection  near  the  end  of  the  transit  than 
near  the  beginning.  To  accommodate  situations  such  as  this, 
the  user  is  permitted  to  specify  a cost  function  over  the 
entire  course  of  his  transit. 

The  final  step  in  the  transit  plan  definition 
sequence  is  the  assessment  of  costs  for  the  various  evasive 
actions  which  may  be  employed  to  thwart  detection. 

2.3.3  Detection  Zone  Algorithm  - The  detection  zone 
algorithm  provides  the  requisite  information  for  plotting 
the  detection  zones  in  Figure  2-3.  In  the  current  Aid,  it 
uses  hypothetical  orbital  paramieters  for  five  surveillance 
satellites.  In  an  operational  decision  Aid,  the  ephemeris 
data  for  satellites  would  be  supplied  and  updated  regularly 
by  a land-based  computer  network. 

The  output  of  the  detection  zone  algorithm  may 
be  sximmarized  in  a table,  as  illustrated  in  Figure  2-6. 

2.3.4  Probabilistic  Information  - Probabilistic  infor- 
mation is  used  in  the  dynamic  progreim  to  calculate  the 
probability  that  the  task  force  will  be  detected  when  it 
passes  through  a detection  zone.  This  information  includes, 
for  example,  the  probability  that  the  weather  is  OK  for 
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detection,  the  probability  that  the  satellite  is  operating 
if  the  weather  is  O.K.,  and  the  probability  that  the  satellite 
will  detect  the  task  force  if  it  is  operating  and  the  weather  \ 

is  O.K.  The  way  in  which  these  probabilities  depend  on  the 
particular  detection  zone  under  consideration  must  be  care- 
fully specified. 

For  example,  the  probability  that  weather  is 
O.K.  for  detection  depends  on  when  and  where  the  detection 
zone  occurs  and  on  the  satellite's  sensors  (optical  sensors 
would  be  defeated  by  cloud  cover  whereas  radar  sensors  would 
not) . Also,  the  probability  of  detection  given  that  the 
satellite  is  operating  and  the  weather  is  O.K.  depends  on 
what  local  cover  and  deception  tactics  the  commander  can 
employ  (COMINT  sensors  would  be  defeated  if  the  commander 
employs  EMCON) . 

A complete  probability  model  for  the  Aid  has 
been  specified,  but  it  requires  probability  assignments  from 
weather  and  satellite  experts.  A practical  way  to  make 
these  assignments  must  be  developed  before  the  Aid  becomes 
operational. 

2.3.5  Decision  Aid  Output  - The  decision  Aid  supplies 
the  commander  with  a recommended  SOA  profile  and,  for  that 
profile,  a listing  of  the  satellite  detection  zones  that 
will  be  encountered.  Computer-graphic  displays  are  shown  in 
Figures  2-7  and  2-8. 
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Figure  2 7 

RECOMMENDED  SOA  PROFILE 


Detection  Zones  under  Recn'd  SOA  Profile 
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Figure  2 8 

DETECTION  ZONES  UNDER  RECM'D  SOA  PROFILE 


3.0  CONCLUSIONS  AND  RECOMMENDATIONS  | 

The  Satellite  Surveillance  Avoidance  Optimization  Aid  | 

described  in  this  report  provides  the  naval  commander  with  a j 

significantly  improved  method  for  surveillance  avoidance. 

The  Aid  will  not  be  ready  for  actual  deployment,  however,  | 

without  additional  enhancements  or  improvements,  and  one  of  i 

the  main  purposes  of  using  it  at  ACCAT  is  to  investigate  and  i 

develop  needed  enhancements. 

i 

3 . 1  Interface  Enhancements  j 


One  obvious  area  in  which  the  Aid  requires  enhancement  j 

is  in  its  user  interface.  The  manner  in  which  parameters  i 

are  requested  and  results  are  presented  is  a matter  which  ! 

involves  subtle  psychological  factors  and  is  often  subject 
to  personal  taste.  DDI  has  considerable  experience  in  the  , 

design  of  man-computer  interfaces  and  has  implemented  an 
effective  interface  for  the  Optimizing  Aid.  Nonetheless  the 
Aid  is  certain  to  require  at  least  some  "fine  tuning"  in  j 

this  area.  We  recommend  that  the  user-interface  enhance-  j 

I 

ments  incorporated  into  the  Aid  be  based  upon  the  experience  I 

gained  through  the  use  and  testing  of  the  Aid  at  the  ACCAT. 

I 

1 

< 

3.1.1  Avoidance  Profile  and  Detection  Zone  Displays  - j 

One  example  of  a potential  user-interface  enhancement  con-  j 

cerns  the  Intercept  Avoidance  Profile  and  the  Detection  ] 

Zones  displays  shown  in  Figures  3-1  and  3-2,  respectively. 

Both  of  these  displays  indicate  the  points  along  a given 
transit  where  detection  by  a satellite  is  possible,  that  is, 
the  points  for  which  a commander's  transiting  force  lies 
within  a satellite  footprint.  It  is  important  to  note  that 
merely  lying  within  the  footprint  does  not  mean  that  detec- 
tion by  the  satellite  is  certain  or  even  likely.  The  satel- 
lite may  not  be  in  operation,  the  weather  may  be  unsuitable 
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Figure  3-1 

INTERCEPT  AVOIDANCE  PROFILE 


Figure  3 2 

DETECTION  ZONES  UNDER  RECM'D  SOA  PROFILE 


'T’tsiai. 


for  detection,  or  the  evasive  action  employed  may  thwart 
detection.  It  is  desirable,  therefore,  to  know  the  proba- 
bility of  detection  associated  with  each  "intercept.” 
(Detection  probability  is  calculated  during  the  optimization 
process  for  each  potential  detection  zone.  Thus,  no  special 
calculations  are  required  to  provide  this  information) . 
Communicating  the  probability  of  detection  to  the  user  can 
be  accomplished  in  several  ways. 

Two  possible  mechanisms  for  this  are  (1)  to 
label  each  intercept  with  its  probability,  and  (2)  to  display 
subsets  of  the  intercepts  which  exceed  user-specified  proba- 
bility thresholds. 

3.1.2  Single  scale  for  cost  factors  - Another  example 
of  a potential  user- interface  enhancement  concerns  the 
specification  of  relative  costs.  Extensive  psychological 
research  on  the  ability  of  human  beings  to  process  informa- 
tion in  various  judgmental  tasks  has  indicated  that  humans 
are  far  better  at  comparative  judgements  than  at  absolute 
ratings.  This  implies  that  in  order  to  avoid  the  effects  of 
various  cognitive  limitations  that  lend  to  unreliability  and 
inaccuracy  in  absolute  judgmental  tasks,  humans  should  be 
used  as  null  instruments  to  make  direct  comparisons  of 
objects,  e.g.,  "Object  A is  heavier  (or  worth  more)  than 
Object  B.  If  Object  A is  worth  100,  Object  B is  worth  70." 
This  is  one  of  the  reasons  that  procedures  for  scaling  value 
(or  utility)  using  human  judgments  should  utilize  compara- 
tive judgements,  involving  well-established  reference  points. 

In  this  vein,  a procedure  for  establishing  a 
single  scale  that  encompasses  the  relative  costs  of  the 
different  factors  involved  in  the  Optimizing  Aid,  such  as 
fuel  cost,  detection  aversion,  and  evasive  action  cost  might 
be  valuable  so  that  relative  scaling  procedures  that  involve 
direct  comparisons  of  the  different  factors  are  used. 
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The  Aid  could  be  changed  to  provide  the  user  with  a summary 
feature  which  displays  all  the  costs  on  a single  scale,  and 
allows  the  user  to  reset  values  on  that  single  scale. 

3.1.3  Non-numeric  scale  - Operational  navy  personnel 
may  experience  some  difficulty  in  expressing  their  personal 
value  systems  by  means  of  an  arbitrary  numeric  scale  such  as 
the  one  described  above.  To  overcome  this  problem,  it  may 
be  possible  to  assess  at  least  some  of  the  costs  in  terms  of 
a "harder"  metric,  such  as  dollars,  hours  of  delay,  etc. 
Alternatively,  it  may  be  possible  to  develop  an  assessment 
mechanism  which  employs  verbal  quantifiers  rather  than 
numeric  values.  DDI  is  currently  conducting  research  in 
this  area,  attempting  to  exploit  the  current  state  of  the 
"fuzzy  set"  methodology  developed  by  Zadeh  et  al.  It  is 
still  too  early  to  tell  whether  usable  results  will  evolve 
from  this  research. 

3.1.4  Standard  strategies  - Notwithstanding  the  rela- 
tive merits  of  numeric  versus  verbal  quantifiers,  the  parameter 
set  of  the  Aid  allows  the  user  considerable  latitude  and 
flexibility  in  describing  his  particular  value  system  to  the 
optimizer.  The  user  can  define  with  a high  degree  of 
precision  how  much  he  values  avoiding  detection  versus 
employing  the  various  evasive  actions  versus  steciming  at  the 
various  SOA  options.  On  the  other  hand,  having  that  degree 

of  freedom  means  that  the  user  must  give  careful  considera- 
tion to  the  specification  of  his  cost  functions. 

One  can  imagine  situations  in  which  the  naval 
commander  has  a frequently  used  global  objective  in  mind, 
such  as  "avoid  detection  at  all  costs."  Rather  than  re- 
quiring him  to  formulate  a set  of  values  to  Implement  this 
objective  each  time  he  wants  to  employ  it,  it  would  be 
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[ convenient  for  him  to  have  it  available  as  part  of  a set  of 

^ "standard  strategies"  knovm  to  the  Aid. 


The  Aid  could  contain  a set  of  "canned"  strate- 
gies available  to  all  users.  Since  it  is  unlikely  that  one 
could  achieve  universal  agreement  on  the  values  constituting 
any  one  strategy,  let  alone  several,  it  seems  more  practical 
and  useful  to  allow  the  user  to  define  his  own  set  of  standard 
strategies.  When  a commander  has  developed  a set  of  parameter 
values  for  an  objective  which  he  might  like  to  employ  again 
at  a later  time,  he  could  save  it  in  his  personal  collection 
of  strategies.  Over  time  each  collection  could  develop  to 
the  point  of  containing  most  of  the  strategies  employed  by 
its  owner  and  could  save  the  user  considerable  effort  in 
planning  a transit.  Moreover,  with  experience,  the  user 
will  have  tuned  his  strategies  so  that  they  very  closely 
reflect  his  inner  value  system. 

Because  of  its  potential  appeal,  we  recommend 
incorporation  of  such  a standard-strategy  feature  into  the 
Aid. 

3.1.5  Location  name  - The  Aid  currently  requires  the 
user  to  indicate  his  planned  points  of  departure,  destina- 
tion, and  intermediate  track  points  by  specifying  their 
latitudes  and  longitudes.  Since  few  users  have  this  type  of 
information  committed  to  memory  (particularly  the  casual 
user  expected  for  demonstrations  at  the  ACCAT) , we  recommend 
providing  the  optional  capability  to  specify  such  points  by 
location  neune.  With  this  feature,  the  user  will  have  at  his 
disposal  a list  of,  say,  a hundred  of  the  most  commonly  used 
ports  and  operational  points  of  departure  and  destinations. 

The  user  will  then  be  able  to  specify  a transit  from  Norfolk 
to  Gibraltar  simply  by  answering  "Norfolk"  and  "Gibraltar" 
in  response  to  the  requests  for  point  of  departure  and 
destination. 
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3.2  Evasive  Action  Options 


For  initial  testing  and  demonstration  of  the  Aid,  we 
have  defined  seven  evasive  action  possibilities  for  thwarting 
the  satellite  sensors  (including  the  "non-action,"  Normal 
Operations).  While  this  set  of  actions  is  representative  of 
an  operational  environment,  it  is  not  as  rich  as  it  might 
be.  For  example,  the  evasive  action  list  contains  only  one 
EMCON  option,  defined  to  be  "total  EMCON"  in  which  all 
transmitters  are  assumed  to  be  turned  off.  Other  types  of 
EMCON  could  be  defined  as  follows  (in  order  of  decreasing 
restriction  from  total  EMCON) : 

o Allow  UHF  communications  for  vital  reports  only. 

o Allow  discrete  (intermittent)  use  of  active  radar 
search  eind  air  control  systems. 

o Allow  use  of  beacon  trac)cing  and  target  identifica- 
tion systems. 

o Allow  use  of  HF  radio  tactical  reporting  systems. 

o Allow  full  use  of  tactical  surveillance,  defense, 

and  air  control  systems. 

o No  restrictions. 

(Each  of  these  options  includes  the  use  of  all  systems  per- 
mitted at  each  higher  level.) 

Most  of  the  other  evasive  actions  in  the  current  set 
could  be  expanded  into  more  precisely  defined  options  as 
well.  We  recommend  incorporating  the  EMCON  options  defined 
above  into  the  evasive  action  set.  If  the  richer  set  of 
EMCON  options  results  in  significantly  different  probabilities 
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of  detection,  then  soliciting  other  evasive  action  and  cover 
and  deception  (C&D)  options  from  users  at  ACCAT  and  incor- 
porating them  into  the  set  appears  worthwhile. 


3. 3 Sensitivity  Analysis 

Another  feature  which  bears  consideration  is  a capa- 
bility for  sensitivity  analysis.  It  would  be  beneficial  for 
the  user  to  explore  the  consequences  of  varying  his  departure 
and  arrival  times,  varying  intermediate  points  in  his  track 
plan,  varying  his  SOA  options,  or  varying  his  cost  functions. 
Unfortunately,  variations  of  this  sort  require,  at  a minimum, 
iteratively  performing  the  optimization  calcv’lations , and  in 
many  cases  recalculating  potential  satellite  intercepts  as 
well.  Since  these  are  relatively  costly  undertakings,  this 
sort  of  "brute  force"  sensitivity  analysis  appears  reasonable 
only  when  there  is  little  constraint  upon  the  computer 
resources  available  and  when  there  is  ample  time  available 
before  actual  departure. 

This  does  not  preclude  the  development  of  sensitivity 
analysis  features,  however.  One  sort  of  sensitivity  analysis 
mechanism  which  may  be  feasible  is  to  permit  the  user  to 
specify  probability  density  functions  for  parameter  values 
(rather  than  point  values)  and  to  generate  corresponding 
outcome  value  distributions.  This  could  result  in  the 
generation  of  several  SOA  profiles  with  associated  expected 
levels  of  effectiveness.  We  recommend  investigating  mechanisms 
of  this  sort  and  implementing  one  which  appears  to  provide 
the  greatest  level  of  feedback  to  the  user. 


3, 4 SOA  Constraints 

In  an  operational  environment,  there  are  situations  for 
which  a naval  force  must  limit  its  SOA  options  to  a subset 
of  those  generally  available  for  a given  transit.  For 
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example,  at  a giver  point  in  the  journey,  it  may  be  neces- 
sary to  conduct  replenishment  operations,  in  which  case  the 
commander  might  wish  to  restrict  his  SOA  to  10  knots  for  a 
specific  eight-hour  period.  As  another  example,  in  inclement 
weather  the  commander  might  wish  to  go  no  slower  than  10 
knots  to  maintain  steerageway  and  yet  may  be  unable  to 
exceed  15  knots  because  of  the  sea  conditions. 

To  accommodate  situations  such  as  these,  we  suggest 
providing  the  capability  for  the  user  to  specify  for  selected 
time  periods  SOA  constraints  which  restrict  the  number  of 
SOA  options  to  be  considered  by  the  optimizer  to  a subset  of 
the  SOA  options  defined  for  the  transit. 

3 . 5 Cost  Function  Segmentation 

In  planning  a particular  transit,  the  naval  commander 
may  choose  his  course  in  such  a way  that  his  cost  functions 
(detection  aversion,  fuel  cost,  and  evasive  action  costs) 
and  the  efficacies  of  the  various  evasive  actions  are 
significantly  different  over  different  segments  of  the 
journey.  For  instance,  a portion  of  the  route  may  coincide 
with  merchant  shipping  lanes.  In  this  case,  the  effective- 
ness of  reconfiguration  or  EM  spoof  to  simulate  a merchant 
task  force  are  markedly  improved  over  the  effectiveness  of 
these  actions  when  far  removed  from  the  shipping  lanes.  In 
another  situation,  the  route  may  pass  through  an  area  which 
normally  contains  a high  level  of  naval  activity.  For  this 
area  the  commander's  aversion  to  detection  may  be  signifi- 
cantly lower  than  for  the  rest  of  the  journey. 

In  order  to  provide  the  flexibility  desired  for  situa- 
tions such  as  these,  we  recommend  incorporating  into  the  Aid 
features  which  allow  the  user  to  specify  detection  aversion, 
fuel  cost,  evasive  action  costs,  and  evasive  action  level  of 
effectiveness  independently  for  each  segment  of  a journey. 


The  number  of  segments  and  the  extent  of  each  should  be 
selectable  by  the  user. 


3 . 6 Fuel  Consumption 

One  aspect  of  transit  cost  upon  which  many  of  the  early 
users  of  the  Aid  have  focused  is  fuel  consumption.  Although 
the  user  is  expected  to  define  a fuel  cost  function  for  the 
optimizer,  this  cost  function  really  encompasses  more  than 
just  fuel  cost  and  might  better  be  considered  an  "SOA  cost 
function,"  since  it  can  reflect  other  reasons  for  disliking 
one  SOA  more  than  another  (such  as  reduced  steerageway) . 

In  order  to  provide  the  commander  with  a more  concrete 
measure  of  his  fuel  consumption,  reports  on  percentage  of 
fuel  remaining  on  each  of  his  ships  at  destination  might  be 
useful.  The  user  would  be  expected  to  indicate  the  com- 
position of  his  force  by  type  of  ship  and  the  initial  fuel 
load  on  board  each.  Based  upon  the  distance  to  be  traveled, 
the  SOA  profile  recommended  by  the  Aid,  and  known  fuel 
consumption  rates,  Lhc  Aid  could  calculate  the  amount  of 
fuel  remaining  on  each  ship  at  the  end  of  the  transit. 

This  feature  could  provide  the  commander  with  another 
mechanism  for  assessing  the  costs  of  a journey. 

3. 7 Principle  of  Optimality 

The  principle  of  optimality  states  (in  over-simplified  |j 

terms)  that  if  one  deviates  from  an  optimal  strategy,  he 
should  develop  a new  (optimal)  strategy  rather  than  try  to 
reconcile  himself  with  the  old  strategy,  which  in  fact  will 
no  longer  be  optimal. 

The  implications  of  this  for  the  naval  commander  are 
that  if  he  deviates  from  the  SOA  profile  recommended  by  the 
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^ Aid,  he  should  not  attempt  to  "catch  up"  or  resynchronize 

I with  that  profile.  Rather,  he  should  request  a new  SOA 

5 profile  which  is  optimal  for  his  current  set  of  circum- 

t stances.  The  original  SOA  profile  is  optimal  only  as  long 

as  the  force  departs  from  the  stated  point  of  departure  at 
••  the  specified  departure  time  and  follows  the  recommended  SOA 

r profile,  causing  position  as  a function  of  time  to  vary  as 

1 shown  in  the  Intercept  Avoidance  Profile  of  Figure  3-1.  If 

the  force  deviates  from  the  recommended  SOA  profile,  its 
position  will  not  coincide  with  the  curve  of  Figure  3-1,  but 
I’  will  lie  above  or  below  it  at  any  instant  in  time.  While  it 

1 may  be  possible  to  adjust  SOA  in  such  a way  as  to  rejoin  the 

1:'  "optimal"  curve,  doing  so  may  cause  the  task  force  to  pass 

unnecessarily  through  avoidable  detection  zones  (the  vertical 

I' 

lines  of  Figure  3-1) . To  maintain  optimality,  a new  SOA 
profile  is  required. 

Fortunately,  very  little  recalculation  is  required  to 
produce  the  new  SOA  profile  (as  long  as  the  force  has  not 
deviated  from  its  planned  course  and  as  long  as  its  position 
still  lies  within  the  parallelogram  of  Figure  3-1) . By 
saving  the  set  of  optimal  SOA  choices  for  all  lattice 
points  within  the  parallelogram  (instead  of  discarding  them 
once  the  original  SOA  profile  has  been  produced) , the  Aid 
would  have  all  the  information  required  to  generate  an 
optimal  SOA  profile  from  any  position  within  the  parallelo- 
gram. 

In  light  of  the  significant  possibility  of  deviations 
from  the  recommended  SOA  profile  in  an  operational  environ- 
ment, we  feel  that  the  reoptimization  facility  is  worthwhile 
and  we  recommend  that  it  be  added  to  the  Aid. 

3.8  Graphics  Language 

In  an  effort  to  improve  the  response  characteristics 
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of  the  user  interface  software  (currently  resident  in  a 
Tektronix  4051  intelligent  graphics  terminal)  and  to  approach 
a greater  level  of  standardization  for  all  software  installed 
at  the  ACCAT,  DDI  recommends  converting  the  user  interface 
software  of  the  Aid  to  be  compatible  with  the  newly  defined 
Graphics  Language.  Since  the  4051  software  is  written  in 
BASIC  and  the  Graphics  Language  support  software  is  currently 
compatible  only  with  FORTRAN,  BLISS,  and  MACRO,  the  conversion 
will  necessarily  involve  a major  rewrite  of  the  user  interface. 

3.9  SOA  Profile  Evaluation 


The  primary  objective  of  the  Aid  is  to  assist  a naval 
commander  in  his  planning  by  providing  him  with  an  optimal 
SOA  profile  for  satellite  surveillance  avoidance.  There  may 
be  situations  for  which  avoidance  of  satellite  surveillance 
is  of  secondary  importance,  however,  and  for  which  a fixed 
SOA  profile  already  has  been  selected  (perhaps  to  minimize 
the  chance  of  detection  by  acoustic  sensors) . 

In  its  larger  role  as  a planning  tool,  the  Aid  could 
also  function  as  an  evaluation  mechanism.  Given  a specific 
SOA  profile,  the  Aid  could  at  a minimum  inform  the  user  of 
the  detection  zones  which  the  force  will  encounter.  It 
could  also  suggest  the  appropriate  evasive  action  to  minimize 
the  cost  of  detection  for  each  zone.  In  addition,  it  could 
provide  a comparison  of  the  cost  and  probability  of  detec- 
tion over  the  transit  for  the  given  SOA  profile  and  the 
optimal  SOA  profile. 

As  a step  in  the  evolution  toward  a comprehensive 
transit  planning  aid,  we  suggest  incorporating  the  SOA 
profile  evaluation  features  into  the  current  Aid. 


i 
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3.10  Other  Enhancements 


Although  this  list  of  possible  enhancements  is  not 
exhaustive,  we  feel  that  it  is  representative  of  a larger 
set  of  potential  enhancements,  some  as  yet  unspecified.  We 
plan,  therefore,  to  be  alert  to  the  possible  existence  of 
such  enhancements,  extensions,  and  modifications  to  the 
Optimizing  Aid  and  to  implement  those  which  appear  most  cost 
beneficial. 

3.11  ACCAT  Installation 


The  Aid  is  currently  installed  at  DDI  on  a Tektronix 
4051  intelligent  graphics  terminal  and  a PDP-11/40  which 
acts  as  the  host  computer.  In  accordance  with  the  goal  of 
demonstrating  and  testing  the  Aid  in  the  ACCAT  environment, 
the  Aid  must  be  installed  on  ACCAT  hardware,  which  is  pre- 
sumably a 4051  terminal  and  a PDP-10  or  a DECsystem  20. 

Although  no  major  obstacles  are  expected,  some  software 
modifications  will  be  required  to  effect  the  transfer.  In 
particular,  those  portions  of  the  software  which  deal  with 
communications  and  I/O  and  those  which  contain  word- length 
dependencies  will  have  to  be  changed.  Most  of  the  modifi- 
cation effort  will  be  concentrated  on  the  host  software. 

Only  the  "login"  and  host  communication  portic”.  of  the  4051 
software  will  be  affected. 


3.12  Installation  and  User  Support 

In  order  to  facilitate  use  and  demonstration  of  the  Aid 
in  the  ACCAT,  DDI  recommends  providing  training,  consultation, 
and  software  support  services  for  ACCAT  personnel.  During 
a twelve-month  period,  we  expect  that  several  trips  to  NOSC 
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of  two  or  three  days'  duration  would  be  required  to  accom- 
plish this  task.  As  part  of  this  task,  appropriate  doc\imen 
tation  on  the  use  of  the  Aid  in  the  form  of  a users'  guide 
should  be  provided. 
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